문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 CPU 게이트 (문단 편집) ==== 심각성 ==== 커널 권한을 가지고 있지 않은 프로그램에서 커널 메모리를 읽을 수 있다는 것은 현대 컴퓨터의 보안 체계를 뒤흔들 수 있는 위험성을 가지고 있다. 다만 멜트다운 취약점 자체만으로는 커널 메모리의 읽기만 가능하고 쓰기는 불가능하므로, 직접 시스템에 파괴적인 행동을 하거나 [[랜섬웨어]] 등 악성코드를 심는 것은 불가능하다. 이 취약점을 이용하기 위해서는 어떤 식으로든 다른 방법을 통해 먼저 시스템에서 공격하는 코드를 알아내야 한다. 그러니까, 알려진 바 대로 갑자기 전세계 대부분 컴퓨터의 보안이 무력화 되는 것은 아니다. 그리고 한가지 더 알아야 할 것은 '''취약점이 있긴 해도 이용을 하기가 너무 어렵다'''는 것이다, 커널 메모리를 읽을 수 있어도 정확한 시간에 정확한 곳을 읽어야 의미가 있는 건데, 실험 환경이 아닌 일반적인 컴퓨터에서 그 정확한 곳을 알려면 본문에 설명된 멜트다운/스펙터의 원리를 궤뚫는것 보다 훨씬 더 복잡한 지식이 필요하다. 그래서 분명 전세계 대부분의 컴퓨터에 있는 취약점이지만, '''2023년 현재까지도 단순히 시연 목적이 아닌 실제 상황에서 의미가 있는 해킹을 성공했다는 보고는 한 건도 없다.''' 하지만 그렇다 해도 이 보안 문제점은 평소엔 기를 쓰고 보려고 해도 볼 수 없었던 커널 메모리의 내용을 쉽게 들여다 볼 수 있는 치명적인 결함이 명백하며, 읽기 전용의 한계도 물리적 보안을 뚫고 별도의 해킹 프로그램들과 연계하면 당연히 커널 메모리를 읽는다는 점에서 위협적이라는 것은 명백한 사실임이 분명하다. 현대의 보안 프로토콜은 비대칭키 기반 암호화 알고리즘을 사용하는데 이 암호화 알고리즘이 작동할 때에는 CPU에 특징적인 어떤 '흔적'이 발생한다. 이 흔적을 추적하여 멜트다운 공격을 시도하면 암호화에 사용되는 개인키를 유출할 수 있고 개인키가 유출된 시스템은 그 이후의 모든 통신을 수신, 변조, 사칭할 수 있다. 또 다른 문제는 멜트다운 취약점을 이용할 때는 특별한 징조를 보이거나 증거를 남기지 않는다는 것이다. 일반적으로 보안 취약성을 악용하는 코드는 이용하는 명령 자체가 시스템에 기록이 남기 쉬운 명령을 이용하거나 권한을 얻는 과정 등 기존에 시스템에서 이용하던 동작을 이용하던 과정에서 취약점을 이용하고 이 과정에서 흔적을 남기거나, 또는 특정 보안 취약성에 맞게 작동하는 과정에서 코드 및 명령어 자체가 특정한 패턴을 보이는 경우가 많다. 하지만 멜트다운 취약점은 훨씬 범용적인 명령어 및 동작을 통해서 이용이 가능하다. 따라서 작동의 감지도 어려울 뿐 아니라 해당 코드가 공격 코드인지 판단하는 것도 어렵다. 하드웨어적 취약성이기 때문에 OS 환경 제약을 받지 않는 다는 것 역시 문제다. 보통 맥OS나 리눅스에서는 대부분 사용자 권한만 가지고도 대부분의 악성코드를 차단할 수 있었지만 위에서 보았다 시피 자바스크립트 가지고도 동작이 가능했기 때문. 무엇보다도 절망적인 것은 멜트다운 취약점의 원인이 십수년간 변하지 않은 (특히 인텔) CPU '''하드웨어 구조적 문제라 업데이트같은 소프트웨어적 해결책으로 완전한 해결을 보장할 수 없다는 것'''이다. 이는 그 어떤 소프트웨어이든 하드웨어 위에서 구동되는 이상 어쩔 수 없는 한계다. 실제로 소프트웨어적인 패치는 모든 멜트다운 공격을 막을 수 없다는 전문가 [[http://www.speconomy.com/news/articleView.html?idxno=102529|의견]]이 있다. 즉 실질적으로 멜트다운 취약점을 이용하지 못할 정도로 업데이트가 가능할 수도 있지만, 그렇게 되지 않을 가능성도 있는 것이다. 설령 공격의 난이도가 높아도 취약점 공격의 대가가 크다면 이용의 어려움이고 뭐고 없이 달려들 수도 있는 것이고. 이 문서에 서술된 '멜트다운' 취약점에 한정한다면 OS의 최적화 과정을 포기해서 커널과 유저의 페이지 테이블을 분리하는 정도로도 충분한 방어가 가능하지만, 이건 CPU 자체의 한계를 해결한 것이 아니라 그 약점이 악용될 가능성 중 하나를 막은(혹은 어렵게 한) 것에 불과하다. 즉, 구조적으로 하드웨어 차원에서 해당 문제의 근본적인 해결이 되지 않는 한 해당 취약점을 악용할 가능성은 남아 있을 수 있다. 그리고 이런 경로 모두를 실제 악용 전에 미리 발견하는 것이나, 설령 발견하더라도 소프트웨어적인 해결책을 찾아내는 것은 현실적으로 매우 어렵다. 인텔 CPU 사용시 설령 성능 저하가 있더라도 OS가 이 문제를 틀어막아주지 않으면 안되는 이유다. 따라서 기존의 보안 문제하고는 차원이 다르게 범용성 높은 취약점이다. 다만 커널의 어느 값이나 쉽게 읽을 수 있을 뿐 어디를 읽어야 하는지 알아내는 과정에는 상당한 연구가 필요하고, 그렇게 기를 써서 뚫어봤자 캐낼만한 값진 정보를 가진게 아니기에 당장 개인 사용자를 타겟 삼아서 취약점을 악용하는 사례는 나오지 않을 가능성이 높다. 그러나 기업이나 공공기관 같은 곳은 일단 뚫기만 한다면 매우 값진 기밀 정보를 담고 있을 것이 100%이기에 무슨 짓을 해서라도 접근하려는 시도가 많아질 수 있으며 무엇보다 타인과 공동으로 사용하는 클라우드 환경 역시 매우 취약해지게 된다. 일단 구글에서는 구글 클라우드의 가상화 시스템의 특성상 멜트다운/스펙터 취약점을 이용하는 것이 불가능하다고 발표했지만 다른 곳도 안전하다는 보장은 없다. 만약 패치로 보안 문제를 완화하는데 실패할 경우, 결국 CPU를 완전히 바꿔야 하는데, 인텔의 경우에는 2011년 [[샌디브릿지]] 아키텍처 기반의 2세대 코어 i 시리즈부터 거의 모든 CPU가 해당되며, 잠재적으로는 '''1995년 11월'''에 등장한 [[펜티엄 프로]]부터, 일반 사용자 기준 1997년 5월에 등장한 [[펜티엄 2]]부터 해당되는 거의 모든 인텔 CPU에 취약 가능성이 있으므로, 현재로선 다른 인텔 CPU로 교체라는 선택지는 사실상 존재하지 않는다. 이렇게 되면 결국 인텔의 CPU를 AMD의 [[AMD ZEN 시리즈|ZEN 아키텍처]] 기반 CPU로 옮기는 것 외엔 방법이 없다. 이로 인해 들어갈 각종 비용은 계산이 어마어마하다는 것은 조금만 생각해 봐도 알 수 있다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기